A business process is a series of enterprise tasks, often undertaken for the purpose of creating valuable output for an internal or external customer. For instance, a business process may give organizational actions structure across time, place, and functions. Business processes have become a chosen means to describe, analyze, execute, and control operational structures across departments, business units, and even business partners.
Business process management (BPM) aims at their improvement for the sake of overall business success. Amongst others, software-enabled business process automation is an instrument to increase process efficiencies and effectiveness. Business process models have been established to specify processes throughout BPM projects. For automation purposes, for example, they document and structure process information prior to their transformation into executable (e.g., code-based) specifications. Modeling and transformation oftentimes are prerequisites for sound process automation.
Business process models help describe the logical and timely flow of business processes as a map. They may help visualize process activities as graphical symbols, possibly connecting them to a linear or other order. Logical operators may indicate when the flow splits into alternative or parallel paths, when they merge again into one, etc. This so-called control flow is a part of a business process model. The control flow may be complemented by additional model elements that differ depending on the perspective. A conceptual-organizational perspective targets the organizational process context including, for example, intra- and inter-organizational division of labor, interaction between human activities, their technical support, product outcome, etc.
The modeling language EPC (event-driven process chain) has prevailed as a de-facto standard for such conceptual business processes. It complements process activities by organizational resources responsible, input required, and output produced, supporting software application systems, organizational objectives, risks, etc. While being rather easy to use even by non-technical process analysts, it also includes important information on the logical flow, which makes it a semi-formal requirements basis for technical process implementation. It is at the transformation from conceptual into technical business process models where business process modeling changes the perspective from organizational design into technical engineering.
Model-driven process automation passes the control flow described in a conceptual business process model on to a technical business process model. Here, it is complemented by technical information such as, for example, process variables for storing process information during execution, online forms for user interaction, exceptions and their handling, communication patterns (asynchronous/synchronous), consistent data exchange, etc. To make a process executable, process activities typically are assigned to automated software functionality or to semi-automated user interfaces. Depending on the chosen modeling language and the targeted deployment system, this transformation may result in a second graphical diagram (e.g., in BPMN 2.0), directly into a code-based script (e.g., XPDL, BPEL, or the like), etc.
The resulting technical process models are to be deployed into the process engine of a business process management system (BPMS) or workflow management system (WFMS), which allows for starting, executing and tracking instances of this process efficiently.
The idea of using business processes as blueprint for cross-application software systems is as old as the concept of workflow management systems (WFMS) and enterprise application integration (EAI). One factor making business process automation a real technical challenge, though, is the plethora of heterogeneous and increasingly distributed software systems to be integrated and connected along a given process flow.
Most recently, service-oriented architectures (SOA) has attempted to meet this integration challenge by exposing and integrating remote software functionality through well-defined software service interfaces. Early proponents conceived of SOA instead as a specific style of distributed software architectures based on the so-called find-bind-execute relationship between service providers and consumers. More recent notions advance this integration view towards the potential SOA offers for business process automation. They put process automation into the center of the SOA discussion. The capability to compose services loosely opens new avenues to implementing business processes flexibly following dynamic business requirements. The adoption of standardized service interfaces allows for the reusing of services in different business processes, as well as flexibly replacing services according to evolving business requirements. In this sense, SOA has been considered a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains.
Web services represent one of the most recent incarnations of service-oriented software technologies. Unlike previous service technologies, web services leverage and further protocol and data standards.
Scientific discourse and best practices of service-oriented architectures provide a number of service-oriented design principles. While the SOA approach reinforces well-established, general software architecture principles of interface-orientation, interoperability, autonomy, and modularity, it also adds additional themes of process-orientation.
Thus, service-oriented design seeks to improve business process flexibility by the separation of process structure (e.g., process flow) and process institutionalization (e.g., selection of service capabilities conducting process activities). Business process systems benefit from service-orientation in several aspects. First, process structure is revisited to prepare for well-defined, comprehensive functional interfaces allowing plug-and-play services to form new business processes. Second, IT support and technical infrastructure, as well as personnel assignment, are addressed by considering process institutionalization alternatives. They affect cost-effectiveness as much as load balancing and performance figures. Third, aspects of data redundancy and data integration are of interest for service-oriented business process systems (SO-BPS), since cross-organizational service provision risks to increasing data redundancy and data control.
Service identification, which involves locating process activities that appear worthwhile being exposed as service, is considered a part of service-oriented system engineering and is at the crossroad between conceptual and technical business process models. Furthermore, service identification typically is one of the first conceptual activities to be conducted in an SO-BPS project. Quality of identified service candidates helps determine overall system quality to a large extent. Flaws in this activity can propagate to all later activities, potentially causing cost-intensive iterations. Because of the potentially high impact of service identification, systematic and thorough techniques are desirable. Potential service functionality can be searched for in different contexts. While the business context sets the structural and behavioral service requirements, the IT context represents existing software systems as possible service providers. However, as the latter refers to an IT inventory analysis, it risks ignoring real business needs. Therefore, service identification in this case is considered as transforming business process requirements into well-defined service requirements.
It is noted that a majority of current service-oriented development models take business process models into account. However, it is believed by the inventor of the instant application that none of these current approaches specifies which prerequisites must be met by business process models to be a suitable basis for service-oriented system design. Indeed, they must meet some minimum design standards to be a useable blueprint for service identification as a prerequisite for service composition and process automation.
Therefore, service identification remains a purely manual consulting service missing any systematic and quantitative support. Service identification has been addressed as a major activity of various academic service-oriented development models, but it hardly has been taken on by SOA governance software. Even so, they are mostly vague guidelines that apparently lack any metric to evaluate service candidates quantitatively. Some service identification approaches miss taking process or business structures into account by only technically analyzing software landscapes for service exposure. The existing few approaches that identify service eligibility of a process function in enterprise models are limited to one service design principle (e.g., data cohesion) and do not leverage contextual information stored in extensive business process architecture models. Thus, it is believed by the inventor of the instant application that none of the existing tools and methods available provides an automatic mechanism (e.g., an algorithm) to identify service candidates among business process functions.
Thus, it will be appreciated by those skilled in the art that there is a need in the art for techniques that provide an algorithmic and/or programmatic approach to identifying service candidates from among business process functions.
One aspect of certain example embodiments of this invention relates to using conceptual business process models as a comprehensive and valuable information basis for service identification.
An aspect of certain example embodiments of this invention relates to an algorithmic and/or programmatic approach to identifying service candidates from among business process functions.
Another aspect of certain example embodiments relates to evaluating a process step as a service candidate.
Another aspect of certain example embodiments relates to providing governance support for service planning governance process, while also linking to business process models and incorporating business-oriented modeling.
Another aspect of certain example embodiments relates to analysis features that support domain composition (which describes service requirements from business processes) for service identification.
Another aspect of certain example embodiments relates to an algorithmic and/or programmatic tool for business process-driven service identification.
Still another aspect of certain example embodiments relates to the flagging of indicators for reusability.
Still another aspect of certain example embodiments relates to identify service candidates having a richness in business semantics provided by event-driven process chains.
Yet another aspect of certain example embodiments relates to goal-service modeling (GSM) as a second activity complementing top-down process decomposition and bottom-up asset analysis.
Yet another aspect of certain example embodiments relates to determining or calculating indicators including, for instance, process indicators, data indicators, organizational indicators, and goal and event indicators.
Yet another aspect of certain example embodiments relates to representing determined or calculated indicators in a Service Identification and Evaluation Matrix (SIEM).
Yet another aspect of certain example embodiments relates to applying a formula to weight determined or calculated indicators to arrive at a score indicative of the total service eligibility.
Yet another aspect of certain example embodiments relates to comparing total service eligibility scores to a threshold, e.g., to filter out functions that do not qualify as candidates for service eligibility.
In certain example embodiments, a method of analyzing functions of a business process model for possible exposure as service capabilities in a service-oriented business process system is provided. A business process model defined by a plurality of objects is received, with each said object having metadata attributes associated therewith. Business process analysis intelligence is obtained at design time for each said object. Process performance intelligence at run time is obtained for each said object. Indicators corresponding to the design time and run time gathered intelligence are stored together with the metadata attributes for the corresponding object. Via at least one processor of the service-oriented business process system, an overall service candidate algorithm is applied to the stored indicators to arrive at a total service eligibility value for each process function in the model.
According to certain example embodiments, a request for a service candidate may be responded to by recommending at least one process function having a sufficiently high total service eligibility value.
According to certain example embodiments, the indicators include or consist of process indicators, data indicators, organizational indicators, and goal and event indicators. According to certain other example embodiments, the indicators include or consist of at least one reusability indicator for functions in the model, at least one data coupling indicator for functions in the model, at least one data cohesion indicator for functions in the model, at least one stakeholder integration indicator for functions in the model, at least one organizational involvement indicator for functions in the model, at least one goal-oriented indicator for service eligibility, and/or at least one event-oriented indicator for service relevance. The total service eligibility value may be a weighted combination of the indicators, and the weights may correspond to one or more objectives to be reached with the resulting service-oriented business process system in accordance with certain example embodiments. As one example, the overall service candidate algorithm comprises, for each said function, obtaining a first value by adding together the expected reusability of the function over a predefined time period, the data cohesion of the function, out-tasking and visibility variables respectively indicating the extent to which execution of the function can be out-tasked to stakeholders and can be made visible to stakeholders, obtaining a second value by subtracting from the first value a degree of data coupling for the function, a maximum number of organizational units involved in the function, and a maximum number of application systems involved in the function, and multiplying the second value by a business relevance indicator for the function to obtain the total service eligibility value for the function. According to certain example embodiments, a function may be exposed as a service capability if the total service eligibility value for the function exceeds a predetermined threshold value.
According to certain example embodiments, the design time intelligence may be gathered by executable program logic such as, for example, scripted macros or reports, and/or the run time intelligence may be gathered via an interface to a process monitoring tool or other executable program logic.
According to certain example embodiments, the total service eligibility values for the process functions may be ranked. For instance, the ranked total service eligibility values may be organized into and/or displayed in groups based on the rankings. In certain instances, the groups may be formed so as to approximate a normal distribution.
In certain example embodiments, a method of defining or refining a business process model is provided. A representation of at least a portion of the business process model is graphically displayed on a display of a computer system, with the portion including a plurality of objects. A user is able to select an object of the model via a user interface. In response to a user request received via the user interface, metadata attributes of the selected object are displayed on the display of the computer system. Indicators corresponding to gathered business process analysis intelligence and/or gathered process performance intelligence are displayed together with the metadata attributes in a matrix format. A total service eligibility value is calculated via at least one processor for each process function in the model based on a weighted summation of the indicators. The indicators corresponding to the business process analysis intelligence are gathered at design time via scripted macros or reports and the indicators corresponding to the indicators corresponding to the process performance intelligence are gathered at run time via an interface to a process monitoring tool.
According to certain example embodiments, a request for a service may be received from the user, and/or at least one service candidate may be displayed to the user as a result of the request. This may in certain instances involve plurality of service candidates are displayed. The service candidates may, for example, be ordered based on their respective total service eligibility values. In some cases, each said service candidate is displayed only if it exceeds a predetermined threshold value. In other example instances, exactly one service candidate is displayed, with the one displayed service candidate corresponding to the function having the highest total service eligibility value.
Non-transitory computer readable storage mediums tangibly storing instructions for performing the above-summarized and/or other methods also are provided by certain example embodiments.
Analogous systems also may be provided in by certain example embodiments. For instance, certain example embodiments relate to a service-oriented business process system for analyzing functions of a business process model for possible exposure as service capabilities. A non-transitory computer readable storage medium includes a representation of the business process model, with the business process model being defined by a plurality of objects. Each said object has metadata attributes associated therewith, and the metadata attributes also are stored in the computer readable storage medium. A first computer-executable intelligence gathering module is configured to obtain business process analysis intelligence at design time for each said object. A second computer-executable intelligence gathering module is configured to obtain process performance intelligence at run time for each said object. A computer-executable analysis module is configured to (a) receive indicators corresponding to the design time and run time gathered intelligence, and (b) apply a service candidate algorithm on some or all of the indicators to arrive at a total service eligibility value for each process function in the model. The modules are executable via at least one processor of the system.
These aspects and example embodiments may be used separately and/or applied in various combinations to achieve yet further embodiments of this invention.